我是怎么踏上低代码这条不归路的
参与低代码建设的理由会有很多，有的人可能是希望提供一套上手门槛足够低的工具，让更多的人能够享受到编写代码的乐趣（Workflow），也有些人是听到了市场上经常出现的「只差一个程序员」的声音，希望为这些有梦想的人提供一套快速实现梦想的工具，更有些人是因为工作调动、入职被分配去做低代码方向之类的。
而我比较特殊，确切的来说，我是被坑过去的。。。
一切要从去年 11 月的某个下午说起
开端
作为手厂（Hand）一枚前端实习生，去年还是一个刚转正的日子。虽然在很久以前就听说研发中心内部在折腾 Lowcode，但是看了看那边投入的大量精英（2-3 名工龄 10 年以上的资深技术，我的导师作为成员之一在那边带队），再看看自己菜到不行的个人实力，在那个时间点上我是绝对不会把自己跟高大上的 Lowcode 项目联系到一起的。
然后就到了那个转折点，某个风和日丽的下午，我的导师把我拉进了会议室，在会议室上将我隆重的介绍给了中台的成员，告诉我后续大家会共同建设新的 Lowcode 系统。
说实话，当天下午接到这个通知的时候，我整个人是懵逼的。内心 os 如下：这项目不是早在 9 月初就交给中台了吗？为啥还需要我去参与建设呢？研发中心建设 Lowcode 都快一年了，叫我这么个菜鸡去建设 Lowcode 是想干嘛？
紧接着就发生了一系列如同电视连续剧般狗血的剧情：
- Day2 -- 研发中心经理通知部门解散，后续所有人员将会并入中台
- Day3 -- 导师离职，LastDay 定在第二天，留给我的最后一句话是「中台需要你」（PS：中台研发实力常年弱于研发中心，一般只有淘汰的人才会被派过去，因为这个被同事嘲笑了近半年😅）
- Day4 -- 导师负责的 UI 框架（其他文章中提到过的 Choerodon-ui/pro）无人维护，中台交付项目陷入短暂的混乱期
- Day5 -- 研发中心近 80% 的人员相继在一周左右集体离职（集体跟研发老大出门创业去了，主打即 Lowcode 产品）
- Day 10 -- 过去曾由我负责的代码仓库被研发中心的前同事（一个月前离职）删除
- Day 12 -- 中台相关人员来找我确认 Lowcode 相关事宜，并询问我导师是否与我有所交接（如果说走前留了句话也算交接的话。。）
然后这个 Lowcode 项目就莫名其妙的到我手上了，没有交接，没有预研。至于成果嘛，这个才是最气人的，下面说项目状况的时候会提到。
项目状况（立项初）
我接下来会从背景、内部情况以及外部情况三部分来做简单的介绍
背景
从董事会的视角看，Lowcode 项目自立项（去年四月份）起已经研发了近 8 个月了（正式接手于 12 月初），交接的项目产物，事后按照我和老板的看法，我们一致认为就是学生大作业水准。至于原因嘛，直到执行四个月后我才从知情的同事那边得知真相：因为研发的老大早有带产品出去创业的意图，当时交付的产物仅仅是为了糊弄董事会而粗制滥造出的产物（这个所有参与人都承认），对于 Lowcode 最为珍贵的实施经验没有半点交接给中台。
当时唯一已知的消息是，部门内大量推行的 DataSet 是基于 Lowcode 这个需求才特地抽象出来的（后期获得更多消息后，发现这个消息可谓是错的不能再错了）。根据这个信息，我们选择了模型建站的思路，开始了艰难的尝试。
内部情况
整体团队构成：中台调动过来的人员，以及研发转岗至中台的人员，团队内没有一个人具备 Lowcode 开发经验，对市面产品状况也不了解。中台调动人员大部分未负责过研发项目，多为交付项目上捞回来的人。而交付人员最大的问题在于：对产品没有长远规划、代码质量差（因为交付项目只管工期内完成任务，做完验收通过就跑路）以及不愿意做不确定成果的事情（交付项目大多为重复页面，熟练后工作非常轻松，这与研发项目存在本质上的不同）。
老板原先负责移动端中台的相关建设，接手 Lowcode 是由董事会强加的，高层对中台施加了相当大的压力，要求在今年 3 月必须拿出 alpha 版本。而老板当时的状态也不看好 Lowcode 这类产品，而更愿意投入时间到开放平台及应用市场部分。
外部情况
业界 Lowcode 产品虽然不算多，但是依然存在 Mendix 与 Outsystems 这类一线产品。自立门户的研发中心在短短两个月内拿出了自研 Lowcode 的第一个版本，期间针对公司以及我个人的嘲讽络绎不绝（即今年 2 月至 3 月这个时间段内）。
小结
由上面的叙述可以很明显的发现，立项 Lowcode 时的内外压力绝不算小。不论是公司内还是公司外，对我们这个新兴团队的质疑声从来没有停过，直至正式 Release 后依旧如此。
认识云凤蝶
很多同学会对我是如何与云凤蝶搭上线感到好奇，实际上对我而言，这仅仅算是一个巧合而已。
去年 12 月做 Lowcode 产品调研时，我们对研发中心过去研究的明源云做了深度调研。说实话，明源云这款产品我到现在都不喜欢，残废一般的设计器，all in one json 式的管控，配置莫名其妙的模型，怎么看都像是一款三流产品。然而我们的产品仿佛就像是跟这款产品较上劲一样，凡事必称明源云，任何需求都要加一句：明源云就是这样做的。
「求其上，得其中；求其中，得其下；求其下，必败」 -- 孙子兵法
本着上述思路，当时的我清晰的认识到，如果我希望让 Lowcode 在公司内长期存在下去，以明源云为师绝对是一条必死之路，后面得知的内部消息同样证明了我的看法（他们的 Lowcode 已经停止迭代近两年了😂）。
既然产品靠不住，团队内势必需要一个能够承载这一职责的人。作为团队内最希望 Lowcode 活下去的人（主要是跟研发中心旧部斗气），我决定主动承接竞品分析这一职责，主动去看看市面上的优秀产品是怎么做的。然后在某个刷知乎的下午，我忽然间刷到了云凤蝶。
当时对可视化搭建体系一窍不通的我，甚至分不清模型建站和非模型建站的区别。单纯的觉得导入 npm 资产很 cool，以及画布上能够自由拖拽的体验非常好。为了逆向这两项亮点功能，我曾经断断续续的做过近半年的研究（然后今年莫名其妙进了团队直接看源代码），期间做过无数版技术设计，如此长期的投入也仅仅摸到了 npm 资产导入的门而已。不过这都是后话了，本次不做展开。
这么好的东西，自然是要拿到周会上分享一下咯。周会正式会议结束后，我向老板主动展示了云凤蝶，然后我的 boss 陷入了沉思。。。
沉思的原因其实也很简单，打个最简单的比方，这有点类似于两个部落对打，一边还在用石器，另一边已经用上了 ak47 一样的感觉，对整个团队的冲击定然是空前的。
不过到了 alpha 发布前，我们终于找准了产品的定位，它就是辅助编程工具，能够覆盖 30% 的交付场景就已经算是我们胜利了。至于销售额，其利润是远远比不上为公司节约的人力成本的。因此就算阿里做出了类似的东西，也不代表着手厂（Hand）一定没有生存的空间。
当然，我的调研并不仅限于云凤蝶，后期的设计中依然受到了业内许许多多优秀产品的启发（Claris、Mendix、amis 以及诸多逻辑编排工具）。
心态转变
在过去的开发历程中，我的心态发生过几次大的转变： 自我怀疑 => 自我催眠 / 集体催眠 => 背负原罪 => 自我肯定
自我怀疑
项目立项之初，作为完全被动的参与方，当时对于能否承接下这样的一个大项目还是犯嘀咕的。纵观团队内外，以及总体背景来说，这都会是一个高风险与高收益并存的项目。即使发布 alpha 版本后，我的身份也历经多次怀疑（毕竟是刚转正三个月的新人），因此当时经历了相当长的一段自我怀疑期。
自我催眠 / 集体催眠
到了 alpha 版本预发布前的两个月，团队内部已经有人坚持不住退场了，整个 Lowcode 团队也经历了一段频繁交接的时间段（一个月于同一个组交接三场）。而当时的我被研发中心旧部各种花式嘲讽，在这样的环境下，我当时的想法也非常简单：既然你认为我做不到，那我就一定要做给你看看。于是我拒掉了已经接到的下家 offer，开始一心一意的将时间精力全部投入到 Lowcode 上，同时开始了一场漫长的自我催眠过程，坚信不存在做不成的事情。
我和老板在 Last day 前曾单独吃过饭，他认为我是个过度自信的人。其实上远远不是，表现在外的仅仅是自我催眠所营造的幻象而已，有时候团队可能正是需要这样一个过度自信的人才能立住。
至于集体催眠，我自然不是催眠大师，没有什么一个响指催眠一大票人的能力。我做的事情实际上也很简单，就是变相的成为整个团队的压舱石。任何难以搞定的事情，都可以直接带上问题来找我，我会尽自己所能去找到合适的解决方案。同样的，我也绝不会轻易地说某件事情是一定做不到，必然会存在某种变通方案，只是我们没有动脑去思考而已。
是的，这样做的直接后果就是整个研发团队过于依赖我个人。但是这也算是某种变相的取舍，至少自此之后，我在团队内部听不到诸如「Lowcode 项目还能活几个月？」这类话题了。
背负原罪
这个话题可能会让人觉得有些夸张，但是它是手厂（Hand）实施 Lowcode 时真实遇到的迷思。6 月份开始，董事会要求所有的项目不再配备前端资源，所有交付项目一律使用后端 + DataSet 进行交付页面的相关开发。作为重度依赖 DataSet 的低代码项目，这在团队内部引发了一场深度讨论，议题如下：
- 交付项目实施到最后，交付人员是不是变成了 DataSet 工程师？（无独有偶，云凤蝶也有类似的探讨）
- Lowcode 一旦成型，程序员是否会异化为 Lowcode 操作员？目前正在利用 Lowcode 搭建 Demo 页面的产品是否能算是程序员？
- 如果 Lowcode 最终达成了董事会的目标，交付项目上的程序员何去何从？是不是只有制造 Lowcode 工具的程序员才能有活路？
其实上今年 5 月，我也拿这些问题咨询过 1688 的姬无，当时得到的答复是这样的：
Lowcode 工具能够将我们的前端同学从单调的业务逻辑中解放出来，从而去做一些更有意义的事情
观察蚂蚁现目前中台交付的现状，这个答复也不是毫无道理。但是从手厂的实施现状来看，这部分人员如果被优化了，就真的不存在了。因此当时我一度认为，自己正在做的事情是带有原罪的。
自我肯定
这个心态转变的契机就很有意思了，时间点在今年 11 月初，地点位于成都双流机场。
登机前由于疫情的影响，要求登机的每个人都要出示健康码。本来是一件很简单的事情，但我在支付宝小程序中申请四川健康码却遇到了各种各样的奇葩状况：诸如接口 403、页面无故刷新表单数据、搜索组件搜不出来东西等等。最后登机前迫于时间压力，只能随便填一个地点先糊弄过登机口（希望不要因为这个被重新拉去检测）。
随后跟同事聊起这件事时，发现各地的健康码小程序质量都参差不齐，经济发达的城市，往往健康码操作起来就会舒心一些。于是我很自然的想到了这么一种场景：
能不能利用 Lowcode 统一这种简单页面的开发流程？从本质上提升此类应用的使用体验？
其实上简单想想都能发现很多种解法，模版、资产组合、应用市场都可以成为解法之一。从这个角度衍生出去看，是否存在这样的一种链路：Lowcode 提升交付质量 => 优质应用提升了客户审美 => 审美提升反过来倒逼应用质量的进一步提升，这样是否就能变相提升中后台，甚至说是整个企业应用领域的交付质量提升呢？
这确实是一个令人着迷的切入点，未来我也希望朝着这个方向做更深入的探索。
尾声
Last day 前两周，确定交接人选时，我挑选了一位大家看起来难堪重任的新人。作出这个决定的理由也很简单，我厌恶手厂那种拿多少钱做多少事的风气，因此在挑选交接人时，第一时间便排除了老板心中的各种资深员工，而是选择了一名我持续带了半年的新人。其实上在过去的半年间，我能教给他的技术并不算多（因为我自己常年研究业务产品，技术方面也是个半吊子），传授的更多是解决问题与看待问题的方式方法等。
我一直坚信一件事情，新鲜血液的涌入，能在一定程度上改善我过往老东家的各种恶劣氛围，让整个环境趋好。因此我在 Last day 前一天留给他的最后一个任务是：传承我教给你的这些东西，如果改变不了环境，至少从改变自己身边的人开始做起。
他也许也会像我去年一样陷入迷惘吧，不过幸运的是，他不会再面对我过去的那种艰难处境了。
而我在新的平台上能成就什么呢？
谁知道呢？